Renamed README.cvs-commits to README.commits
authorCody Russell <bratsche@gnome.org>
Fri, 17 Aug 2007 15:51:27 +0000 (15:51 +0000)
committerCody Russell <bratsche@src.gnome.org>
Fri, 17 Aug 2007 15:51:27 +0000 (15:51 +0000)
2007-08-17  Cody Russell  <bratsche@gnome.org>

        * Renamed README.cvs-commits to README.commits

svn path=/trunk/; revision=18645

ChangeLog
README.commits [new file with mode: 0644]
README.cvs-commits [deleted file]

index 202c7f01ec64ac1674552a7286f0e217fe6c8112..54d0b10e84c662f808b899a8a4be421b02725c90 100644 (file)
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2007-08-17  Cody Russell  <bratsche@gnome.org>
+
+       * Renamed README.cvs-commits to README.commits
+
 2007-08-17  Cody Russell  <bratsche@gnome.org>
 
        * HACKING
diff --git a/README.commits b/README.commits
new file mode 100644 (file)
index 0000000..4eeeaa5
--- /dev/null
@@ -0,0 +1,54 @@
+GTK+ is part of the GNOME Subversion repository. At the current time, any
+person with write access to the GNOME repository, can make changes to
+GTK+. This is a good thing, in that it encourages many people to work
+on GTK+, and progress can be made quickly. However, GTK+ is a fairly
+large and complicated package that many other things depend on, so to
+avoid unnecessary breakage, and to take advantage of the knowledge
+about GTK+ that has been built up over the last 4 years, we'd like
+to ask people commiting to GTK+ to follow a few rules:
+
+0) Ask first. If your changes are major, or could possibly break existing
+   code, you should always ask. If your change is minor and you've
+   been working on GTK+ for a while it probably isn't necessary
+   to ask. But when in doubt, ask. Even if your change is correct,
+   somebody may know a better way to do things.
+
+   If you are making changes to GTK+, you should be subscribed
+   to gtk-devel-list@gnome.org. (Subscription address:  
+   gtk-devel-list-request@gnome.org.) This is a good place to ask
+   about intended changes. 
+
+   #gtk+ on GIMPNet (irc.gimp.org, irc.us.gimp.org, irc.eu.gimp.org, ...)
+   is also a good place to find GTK+ developers to discuss changes with,
+   however, email to gtk-devel-list is the most certain and preferred
+   method.
+
+1) Ask _first_.
+
+2) There must be a ChangeLog for every commit. (If you discover that
+   you only committed half the files you meant to and need to fix that
+   up, or something, you don't need a new ChangeLog entry. But in general,
+   ChangeLog entries are mandatory.) Changes without ChangeLog entries
+   will be reverted.
+
+3) There _must_ be a ChangeLog for every commit.
+
+Notes:
+
+* If you are going to be changing many files in an experimental fashion,
+  it probably is a good idea to create a separate branch for your changes.
+
+* The ChangeLog entries should preferably match in date format
+  with the existing entries. You can set how emacs does this
+  by using customize mode:
+
+  - M-x customize
+  - set Programming/Tools/ChangeLog/Add Log Time Format to
+    'Old Format'
+
+ Or, set the add-log-time-format to 'current-time-string in
+ your .emacs file.
+
+Owen Taylor
+13 Aug 1998
+17 Apr 2001
diff --git a/README.cvs-commits b/README.cvs-commits
deleted file mode 100644 (file)
index 4eeeaa5..0000000
+++ /dev/null
@@ -1,54 +0,0 @@
-GTK+ is part of the GNOME Subversion repository. At the current time, any
-person with write access to the GNOME repository, can make changes to
-GTK+. This is a good thing, in that it encourages many people to work
-on GTK+, and progress can be made quickly. However, GTK+ is a fairly
-large and complicated package that many other things depend on, so to
-avoid unnecessary breakage, and to take advantage of the knowledge
-about GTK+ that has been built up over the last 4 years, we'd like
-to ask people commiting to GTK+ to follow a few rules:
-
-0) Ask first. If your changes are major, or could possibly break existing
-   code, you should always ask. If your change is minor and you've
-   been working on GTK+ for a while it probably isn't necessary
-   to ask. But when in doubt, ask. Even if your change is correct,
-   somebody may know a better way to do things.
-
-   If you are making changes to GTK+, you should be subscribed
-   to gtk-devel-list@gnome.org. (Subscription address:  
-   gtk-devel-list-request@gnome.org.) This is a good place to ask
-   about intended changes. 
-
-   #gtk+ on GIMPNet (irc.gimp.org, irc.us.gimp.org, irc.eu.gimp.org, ...)
-   is also a good place to find GTK+ developers to discuss changes with,
-   however, email to gtk-devel-list is the most certain and preferred
-   method.
-
-1) Ask _first_.
-
-2) There must be a ChangeLog for every commit. (If you discover that
-   you only committed half the files you meant to and need to fix that
-   up, or something, you don't need a new ChangeLog entry. But in general,
-   ChangeLog entries are mandatory.) Changes without ChangeLog entries
-   will be reverted.
-
-3) There _must_ be a ChangeLog for every commit.
-
-Notes:
-
-* If you are going to be changing many files in an experimental fashion,
-  it probably is a good idea to create a separate branch for your changes.
-
-* The ChangeLog entries should preferably match in date format
-  with the existing entries. You can set how emacs does this
-  by using customize mode:
-
-  - M-x customize
-  - set Programming/Tools/ChangeLog/Add Log Time Format to
-    'Old Format'
-
- Or, set the add-log-time-format to 'current-time-string in
- your .emacs file.
-
-Owen Taylor
-13 Aug 1998
-17 Apr 2001